Assertion failure in get_attstatsslot()
От | Bernd Helmle |
---|---|
Тема | Assertion failure in get_attstatsslot() |
Дата | |
Msg-id | E3625E1446621CD81C62AC9C@[172.26.14.62] обсуждение исходный текст |
Ответы |
Re: Assertion failure in get_attstatsslot()
|
Список | pgsql-hackers |
Consider the following small testcase: BEGIN; CREATE OR REPLACE FUNCTION upper(IN varchar, OUT varchar) LANGUAGE SQL STRICT IMMUTABLE AS $$ SELECT pg_catalog.upper($1)::varchar; $$; CREATE TABLE foo(value varchar); INSERT INTO foo SELECT 'helmle' FROM generate_series(1, 1000); CREATE INDEX foo_upper_index ON foo(public.UPPER(value)); ANALYZE foo; -- assertion failure EXPLAIN SELECT 1 FROM foo WHERE UPPER(value) = 'xyz'; COMMIT; While the sense of the UPPER() function is surely debatable (but it is used in this way in the database where the assertion failure was triggered), the EXPLAIN in the script crashes with TRAP: FailedAssertion("!(((array)->elemtype) == elmtype)", File: "arrayfuncs.c", Line: 2970) LOG: server process (PID 15451) was terminated by signal 6: Abort trap It took me a while to strip that down to this script, because it only happens when the statistics slots of the index are examined for the constant value in the where clause. The stavalues array holds type oid 1043, whereas type oid 25 is expected. I tried it back from current -HEAD to 8.3.11 and managed to reproduce it everywhere. Non-cassert builds are working correctly, so i'm not sure wether this is an over-aggressive assert() or masks a problem from somewhere else. -- Thanks Bernd
В списке pgsql-hackers по дате отправления: